home
***
CD-ROM
|
disk
|
FTP
|
other
***
search
/
ftp.cs.arizona.edu
/
ftp.cs.arizona.edu.tar
/
ftp.cs.arizona.edu
/
icon
/
newsgrp
/
group01a.txt
/
000059_icon-group-sender _Tue Jun 13 07:47:06 2000.msg
< prev
next >
Wrap
Internet Message Format
|
2002-01-03
|
2KB
Return-Path: <icon-group-sender>
Received: (from root@localhost)
by baskerville.CS.Arizona.EDU (8.9.1a/8.9.1) id HAA02504
for icon-group-addresses; Tue, 13 Jun 2000 07:46:28 -0700 (MST)
Message-Id: <200006131446.HAA02504@baskerville.CS.Arizona.EDU>
To: "Frank J. Lhota" <NOSPAM.Frank.Lhota@lexma.meitech.com>
Cc: icon-group@optima.CS.Arizona.EDU
Subject: Re: User defined operators for Icon
Date: Mon, 12 Jun 2000 17:30:38 -0700
From: Clinton L Jeffery <jeffery@bo.Egr.UNLV.EDU>
Errors-To: icon-group-errors@optima.CS.Arizona.EDU
Status: RO
Content-Length: 1525
The discussion of extending Icon with new types is very interesting.
I have a couple additions to the ideas people have contributed so far:
1. You can define the behavior of functions such as image() and write() for
new types, by providing procedures with those names. It is awkward to make
this work when independently written types (say, in procedure libraries)
need to be used together; they can't both supply a definition of image(),
though you can devise passable workarounds for this.
2. You can always get at the original definitions of overloaded functions,
using the proc() function.
3. You can devise explicit type conversion functions between record types
and existing types, you just can't do implicit ones.
Object oriented programming is all about creating a strong facility for
writing user-defined types. I can't say whether operator overloading or
implicit type conversions are appropriate or desirable for Icon, but
Unicon's object-oriented facilities (the successor and replacement for Idol)
would benefit directly from Frank's suggestions.
There are some controversial issues (read this as: "problems") involving
operator overloading and type conversions as found in C++. I will probably
think about them carefully, and discuss them on the Unicon mailing list,
before I go and implement them for Unicon. Besides, I have to finish
implementing packages and get the UNLV release of Unicon for UNIX and
Windows out the door, before I think about any other features. :-)
Clint, jeffery@cs.unlv.edu